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Method and arrangement for indicating requirements for broadcast and 
multicast reception 

Menetelma ja jarjestely yleislahetyksen vastaanottoedellytysten ilmaisemiseksi 

Ett forfarande och en anordning for att indikera krav for broadcast och multicast 
mottagning 

The present invention relates generally to telecommunication systems. In particular the 
invention concerns broadcast and multicast services in wireless systems such as mobile 
networks. 

The terms "broadcast'* and "multicast" refer to methods for transmitting data from a 
single sender to several recipients. In broadcast services basically all users connected 
to the system can in principle, if equipped with a terminal providing sufficient 
capabilities, receive the data if they have enabled the service reception on their Ufi 
(User Equipment) and are located in service range. In multicast services only the users 
who have subscribed to a certain multicast group can receive the data associated with 
said group. 

Traditionally aforesaid point-to-multipoint services in fixed networks, e.g. multicast 
services on the Internet, have provided only minor benefits what comes to the resource 
saving aspects related to the amount of transferred data. Now, the advent of modern 
mobile networks has introduced considerable advantages for resource sharing resulting 
also better overall efficiency because the subscribers of a certain service can receive 
the same data on a common channel thus saving both network and radio resources such 
as time slots, carrier frequencies or hopping sequences. One essential difference 
between fixed and mobile networks is admittedly that efficient bandwidth usage is 
much more critical factor in mobile networks as radio frequencies seem to be the 
scarce resource, and transmission capacity of fixed networks can be increased more 
painlessly after all. 

3GPP (3 rd Generation Partnership Project) has recently published a specification for 
the 3GPP system comprising either UTRAN (UMTS Terrestrial Radio Access 
Network) or GERAN (GSM/EDGE Radio Access Network) as a radio access network. 
The specification defines a new broadcast/multicast service titled MBMS (Multimedia: 
Broadcast/Multipast Service) [1]. 
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MBMS basic architecture is illustrated in figure 1 wherein CBC (Cell Broadcast 
Centre) 102, CSE (Camel Service Environment) 108, OSA/SCS (Open Service 
Access) 1 12 and related reference points can be considered as optional functionalities. 
Accordingly, mandatory components for realizing a MBMS service are described next 
5 in reference to [2]. 

The SGSN (Serving GPRS Support Node) 120 executes user individual service control 
functions, concentrates individual users of the same MBMS service into a single 
MBMS service and maintains a single connection with the source of the MBMS data. 

10 The GGSN (Gateway GPRS Support Node) 122 terminates the MBMS GTP (GPRS. 
Tunneling Protocol) tunnels from the SGSN and links these tunnels via IP (Internet 
Protocol) multicast with the MBMS data source. The BM-SC (Broadcast/Multicast 
Service' Center) 110 is a MBMS data source. MBMS data may be scheduled in the 
BM-SC 1 10 to be e.g. transmitted to the user every hour. It offers interfaces which can 

15 be utilized by the content provider 114 in requesting data delivery to users. The BM- 
SC 110 may authorise and charge content provider 114. The Gmb reference point 
between BM-SC 110 and GGSN 122 enables the BM-SC 110 to exchange MBMS 
service control information with the GGSN 122. The Gmb reference point exists in 
order to carry the MBMS Service information but it may not always be necessary to 

20 use the Gmb for each service. MBMS service can be delivered to user equipment (UE) 
116, 128 such as a mobile terminal over GERAN 130 or UTRAN 118. The SGSN 
authenticates users and authorises the usage of services based on subscription data 
from HLR 106. 

» • 
t 

\ " 25 The architecture also accepts other MBMS broadcast/multicast data sources and 
internal data sources 104 may directly provide their data. Data delivery by external 
sources 126 is controlled by Border Gateways (BG) 124 which may allow for example 
data from single addresses and ports to pass into the PLMN (Public Land Mobile 
Network) for delivery by an MBMS service. 

30 

• » 

. V- The architecture assumes the use of IP multicast at the reference point Gi. The MBMS 

.. data source has only one connection to the IP backbone. The reference point from the 
content provider to the BM-SC 110 is currently not standardized as it might become 

m .~ too complex or too restrictive for service creation. For example, this may be a 

• ; 35 reference point between the BM-SC 110 and an authoring system, or the authoring 

*• functionality may be. distributed between both entities. The same architecture provides 

.„ : MBMS broadcast services mainly by using the transport functions. The user specific 
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SGSN functions are not required. Instead each individual broadcast service is 
configured in the SGSN 120. 

The SGSN 120 may use CAMEL (Customised Application for Mobile network 
5 Enhanced Logic) to handle pre-paid services, e.g. credit checking for on-line charging. 
The Cell Broadcast Centre (CBC) 102 may be used to announce MBMS services to the 
users. The BM-SC 110 may exploit OSA-SCS 112 to interact with third parties. For 
* the terminal split, MBMS shall be able to intemperate with an IP multicast client 

software on the TE. 

10 

MBMS broadcast and multicast service provisions are described in figure 2. ItrMBMS 
broadcast service provision service announcement 202 informs UEs about forthcoming 
services. MBMS broadcast mode bearer set up 204 establishes the network resources 
for MBMS data transfer in the broadcast area. MBMS notification 206 informs the 

15 UEs about forthcoming (and potentially about ongoing) broadcast data transfer. Data 
transfer 208 is the phase when MBMS data are transferred to the UEs. MBMS 
broadcast mode bearer release 210 releases the network resources for MBMS data 
transfer, e.g. when no more transferable MBMS data exists. Service announcement 202 
and MBMS notification 206 steps may run in parallel with other phases, in order to 

20 inform UEs which have not yet received the related service. 

In MBMS multicast service provision subscription 212 establishes the relationship 
between the user and the service provider, which allows the user to receive the related 
, MBMS multicast service. Service announcement 214 informs UEs about forthcoming 

■.^ 25 services. Joining (MBMS multicast activation) 216 is the process by which a 
subscriber becomes a member of a multicast group, i.e. the user indicates to the 
network that he/she is willing to receive multicast mode data of a specific service. 
MBMS multicast mode bearer set up 218 establishes the network resources for MBMS 
data transfer in the multicast area. MBMS notification 220 informs the UEs about 
30 forthcoming (and potentially about ongoing) multicast data transfer. During data 
transfer phase 222 MBMS data is transferred to the UEs. MBMS multicast mode 
bearer release 224 releases the network resources for MBMS data transfer, e.g. when 
no more MBMS data has to be transferred. Leaving 226 (MBMS multicast 
o.; deactivation) is the process by which a subscriber leaves (stops being a member) a 

- • 35 multicast group, i.e. the user no longer wants to receive multicast data of a specific 
* service. The phases subscription 212, joining 216 and leaving 226 are performed 
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individually per user. The other phases are performed for a service provision, i.e. for 
all users associated with the related service. 

MBMS service announcement/discovery mechanisms 202, 214 should allow users to 
5 request or be informed about the range of MBMS services available. This includes 
operator specific MBMS services as well as services from content providers outside of 
the PLMN. Operators/service providers, may consider several service discovery 
t mechanisms including standard mechanisms such as SMS, or depending on the 

capability of the terminal, applications that encourage user interrogation. The method 
10 chosen to inform users about MBMS services may have to account for the users 
location, (e.g. current cell, in the HPLMN or VPLMN). Users who have not .already 
subscribed to a MBMS service should also be able to discover MBMS services. For 
example SMS-CB (Short Message Service - Cell Broadcast), MBMS Broadcast to 
advertise MBMS Multicast Service, PUSH mechanisms (WAP, SMS-PP) and Web 
15 URL (Universal Resource Locator) can be utilized in service discovery purposes. 

More detailed information about MBMS service activation/release models, data 
transfer, functionalities of network elements, radio interface bearer set-up/release, QoS 
(Quality of Service), security issues etc. can be found in the references [1] and [2]. 

20 

.:*•„ Current MBMS specifications don't address UE capability issues in any way. 

However, for example GSM (Global System for Mobile Communication), GPRS 
(General Packet Radio Service) and WCDMA (Wideband Code Division Multiple 
... . Access) terminals vary significantly regarding their data reception and transmission 

\ ■ 25 capabilities. In GSM and GPRS systems mobile terminals have been actually divided 
• • into multislot classes which define the number of time slots a mobile belonging to a 

certain class can utilize in uplink and downlink directions [3]. Another distinctive 
factor in the near future will be EDGE (Enhanced Data rates for GSM Evolution) 
capability, essentially the availability of transmission means supporting 8-PSK (Phase 
30 Shift Keying) modulation and enhanced layer 2 retransmission mechanism. 
Accordingly, in WCDMA the low-end terminals may only support relatively low bit 
.'. rates such as 128 kbit/s e.g. due to insufficient memory or processing power to receive 

•♦♦* and decode higher bit rate (e.g. 384 kbit/s or HSDPA, High Speed Downlink Packet 

Access) video applications etc. 

. 35 

When multimedia broadcast or multicast services are provided to a group of UEs like 
... mobile terminals the data allocation must be done in a way that all terminals belonging 



to the target group can receive the media stream. See figure 3, wherein a terminal is 
capable of receiving data on two time slots 302. If, for example, in GERAN the media 
stream is sent on three adjacent time slots per carrier 304, two time slot capable 
terminals just can not receive the service 306. Also, if higher data rate is to be provided 
by using 8 PSK modulation, only the terminals that support EDGE can receive the 
service. As a consequence, there exists a great demand for defining and notifying about 
what kind of requirements the terminals must meet in order to be able to receive a 
particular MBMS service. The same situation applies to UTRAN with terminals 
providing varying support for bit-rate adaptation and other properties. 

An object of the present invention is to provide a simple and reliable technique for 
indicating requirements for broadcast and multicast service reception. The object is 
achieved with a method and a device which either explicitly or implicitly provide that 
information to a receiving end a priori, before actual attempts by the receiving end to 
receive overly demanding or otherwise incompatible transmission. Thereby, error cases 
can be avoided and average power consumption reduced as the terminal does not need 
to monitor the broadcast blocks it can not receive. 

A method according to the invention for indicating requirements for point-to- 
multipoint service reception in a wireless system is characterized in that in that said 
method comprises the step of transmitting a message indicating said requirements over 
the air interface to at least one terminal within the service range in order to allow the 
terminal to determine whether it is capable of receiving the service or not. 

In another aspect of the invention, a method for indicating requirements for point-to- 
multipoint service reception in a wireless system to be performed by a terminal 
operable in said system, is characterized in that said method comprises the step 
informing terminal's capabilities to said system which deduces on the basis of 
informed data whether the terminal is capable of receiving the service or not. 

In a further aspect of the invention, a terminal operable in a wireless system, 
comprising processing means and memory means for processing and storing 
instructions and data, is characterized in that said terminal is arranged to receive a 
message indicating requirements for point-to-multipoint service reception and arranged 
to determine on the basis of said requirements whether it is capable of receiving the 
service or not. 

In a further aspect of the invention, a terminal operable in a wireless system, 
comprising processing means and memory means for processing and storing 



instructions and data, is characterized in that it is arranged to inform its capabilities to 
said system for the examination of fulfilment of point-to-multipoint service reception 
requirements. 

In a further aspect of the invention, a network element operable in a wireless system, 
comprising processing means and memory means for processing and storing 
instructions and data, is characterized in that it is arranged to send a message indicating 
requirements for point-to-multipoint service reception to be delivered to at least one 
wireless terminal within the service range in order to allow said wireless terminal to 
determine whether it is capable of receiving the service or not. 

In a further aspect of the invention, a network element operable in a wireless system, 
comprising processing means and memory means for processing and storing 
instructions and data, is characterized in that it is arranged to receive a notification 
from a terminal and deduce on the basis of said notification whether the terminal is 
capable of receiving a point-to-multipoint service or hot. 

A system according to the invention comprises a network element and at least one 
wireless terminal operable in said system, and the system is characterized in that said 
network element comprises means for sending a message indicating requirements for 
point-to-multipoint service reception to be delivered to at least said wireless terminal 
within the service range and said terminal comprises means for receiving said 
broadcast message indicating requirements for point-to-multipoint service reception 
and means for determining on the basis of said indication whether it is capable of 
receiving the service or not. 

In one embodiment of the invention a system already comprising CBS (Cell Broadcast 
Service) is supposed to support more versatile MBMS services as well and notify 
terminals in-range about the requirements for service reception in conjunction with 
sending a CBS schedule message disclosing data about MBMS services instead. In 
practise, the requirements are notified by informing the terminals about an applicable 
MBMS capability class. Three different capability classes define the minimum 
capabilities required for receiving available services. 

In another embodiment of the invention a mobile terminal capable of receiving point- 
to-multipoint services informs the system it is connected to about its capabilities such 
as a maximum number of concurrently receivable downlink time slots for joining a 
certain MBMS multicast service. The system checks if necessary minimum 



requirements for the joining/service reception are met and if that is the case, accepts 
the joining request and if not, rejects it. 

The accompanying dependent claims also describe some other preferred embodiments 
'of the invention. 

In the following, the invention is described in more detail by reference to the attached 
drawings, wherein 

Fig. 1 is a block diagram of a MBMS capable system as referred to in the 
description of the background of the invention. 

Fig. 2 depicts provision of MBMS broadcast and multicast services as presented 
in the reference [2] . 

Fig. 3 depicts a scenario, wherein a mobile terminal supports monitoring of two 
time slots per frame and thus is not capable of receiving a service requiring three 
time slots. 

Fig. 4 is a signalling chart disclosing one option for MBMS Broadcast service 
activation and requirements indication as proposed in a first embodiment of the 
invention. 

Fig. 5 is an example of an indication request message disclosed in figure 4 

Fig. 6 illustrates one possible MBMS capability class division according to the 

first embodiment of the invention. 

Fig. 7 illustrates a CBS schedule message in accordance with the first 
embodiment of the invention. 

Fig. 8A is a flow diagram disclosing the first embodiment of the invention 
Fig. 8B is a flow diagram disclosing a second embodiment of the invention 
Fig. 9 A is a block diagram of a wireless terminal, substantially a cellular phone, 
capable of sending and receiving broadcast/multicast data according to the 
invention. 

Fig. 9B is a block diagram of a network element capable of sending and 
receiving broadcast/multicast data according to the invention. 

Referring to figure 4, a signalling chart for MBMS broadcast service activation with 
additional requirements indication messaging as proposed in accordance with the 
invention is illustrated. The procedure is to be performed in a system of figure 1 
comprising a UMTS (Universal Mobile Telecommunications System) core network 
and either GERAN 130 or UTRAN 118 as a radio access network. The service data 
source can be, for example, a multimedia or audio server transmitting tv/radio channels 
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over the network. For example, at a SGSN re-start or when a new MBMS broadcast 
service is set-up, see phase 402, the SGSN 120 requests a creation of an MBMS 
context and GTP tunnel on the GGSN 122 for each RNC/BSC (Radio Network 
Controller, BaseStation Controller) within the service area. In phase 404 the GGSN 

5 122 joins the relevant IP multicast to connect the BM-SC 1 10 if not connected already. 
The BM-SC 110 informs the CBC 102 about a need to notify terminals within the 
service range about the MBMS services including e.g. the requirements for the MBMS 
service reception, see phase 406. In phase 408 the CBC 102 forwards the indication 
request to relevant RNC/BSCs which generate schedule messages indicating said 

10 services and requirements and broadcast them to the terminals in phase 409. It should 
be Noticed that the aforesaid procedure can also be utilized as a general -service 
announcement 202 (figure 2) technique disclosing many other details in addition to the 
actual requirements for the service reception. Link, reference point and protocol issues 
concerning the connectivity possibilities between the CBC 102 and other network 

15 elements including RNC/BSCs in the radio access networks are not discussed here in 
detail and can be found in the reference [4]. In phase 410 MBMS service activation 
continues normally and GGSN confirms the establishment of the MBMS context. In 
phase 412 MBMS data is sent to the GGSN 122 and in phase 414 forwarded to the 
SGSN 120 through all related Gn/Gp tunnels. In phases 416 and 418 a RAB (Radio 

20 Access Bearer) is created for each MBMS context utilizing assignment request and 
assignment response procedures. In phase 420 MBMS notification is sent to terminals 
being finally followed by the transmission of MBMS service data in phases 422 and 
424. Although in this particular embodiment a separate message is constructed for 
announcing the service information like requirements for the reception, also already 

25 existing messages such as the MBMS notification 420 could be used, possibly after 
some modifications to the present structure of the message, for delivering the same 
information. 



The procedure of indicating the MBMS service requirements and possibly other data in 
30 a schedule message may be repeated whenever needed, favourably cyclically. The 
temporal placement of service requirement indication in connection with MBMS 
service activation and RAB set-up can vary as well and above-proposed insertion 
between activation phases 404 and 410 is only a one possible option. Correspondingly, 
it is noted that the presented procedure as a whole can be considered as an example for 
• • 35 clarifying the industrial applicability of the invention, and also other feasible methods 
exist e.g. for the MBMS service activation/release as presented in the reference [2]. 
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The CBC 102 is responsible for the management of CBS messages. In UMTS the CBC 
102 is integrated to as a node into the core network and in GSM it is an external node. 
The CBC 102 may be connected to several BSCs/RNCs. The CBC's 102 
responsibilities include allocation of serial numbers, broadcast initiation, determination 
5 of destination cells, broadcast timing and broadcast repetition timing issues, 
determination of the cell broadcast channels etc. In GSM within a CBC-BSC interface, 
a CBS message is uniquely identified by the quartet (Message Identifier, Serial 
Number, Cell Identifier, Channel Indicator). In UMTS within the CBC-RNC interface, 
a CBS message is uniquely identified by the triplet (Message Identifier, Serial Number, 
10 Cell Identifier). See the references [4], [5] and [6] for further information on the 
technical realization of CBS. 

The steps of requesting the indication 406, 408 can be carried out by sending first an 
indication request message 501, see figure 5, to the CBC 102 containing a message 
15 identifier describing the type of the message 502 , service or context identifier e.g. IP 
multicast address and APN (Access Point Name) of the service under consideration 
504, implicit arid/or explicit service requirements 506, and possibly also other optional 
data such as service delivery goals or "real" schedule data disclosing timing 
instructions 508. The CBC 102 may forward the message 501 to the relevant 
. 20 RNC/BSCs as such, which can be considered as an addition of a new CBC-RNC/BSC 

mm 

: : service primitive type or, for example, modify already existing service primitives to 

: I include aforesaid message elements to minimize changes needed in existing RNC/BSC 

interface. For example, WRTTE-REPLACE primitive disclosed in [4], which is 
normally used to broadcast a new CBS message or replace an existing one, can be 
\: 25 utilized for this purpose by e.g. selecting a certain message identifier for the indication 
*: request procedure and including other necessary informiation 504, 506 into the 

parameters of the primitive. Consequently, RNC/BSC software has to be slightly 
updated in order to receive and execute indication requests. However, changes are 
modest as a corresponding functionality for handling the primitives already exists. 

. 30 

/ In this particular embodiment all available MBMS services have been divided into 

three different MBMS capability classes but in practise, the total number of classes can 
[' be selected as desired. Field 506 includes the class parameter of the current service 

•; under activation. Classes define the minimum capability required to receive the 

\ 35 services properly. A possible scenario with three different classes meant especially for 
GPRS/EDGE capable terminals and GERAN as a radio access network is presented in 
figure 6. 
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For each MBMS service that is broadcast over the air interface the system indicates 
409 the -class of the service i.e. the minimum capability requirements needed for 
reception. This indication is broadcast in a schedule message so that the receiving UE 
5 like a mobile terminal can in advance decide whether to monitor the blocks disclosing 
the service-related information. The rest of the time the terminal may stay in a low 
power consumption mode to save battery. 

In CBS the system broadcasts schedule messages 701, see figure 7, generated by 
10 RNC/BSC containing a bitmap 710 of new CB messages that will be broadcast within 
a predefined period. With this bitmap 710 terminals can in future utilize discontinuous 
reception (DRX) and listen to only those messages they are interested in and have not 
yet received. Bitmap 710 comprises one bit for each message slot, wherein each bit 
refers to the content of the slot being 1 (one) if the slot contains an SMSCB (Short 
15 Message Service Cell Broadcast) message which was either not sent during the 
previous schedule period, or sent unscheduled during the preceding schedule period; 
or, the message is indicated as of free usage, reading advised. The value is one both for 
the first transmission of a given SMSCB message page in the schedule period or a 
repetition of it within the schedule period. Value 0 (zero) means that the definition 
. 20 above does not apply. Schedule message 701 contains a description field 716 for each 
y new (valued 1 in bitmap) CBS message to be broadcast during the scheduling period. 

* ■' For the remaining slots with bitmap value 0 it is also possible to include optional 

descriptions 714 after obligatory new message descriptions 712. Message slot numbers 
" * 726 (1-48) in the bitmap indicate the position of the CBS message within the schedule 

v 25 period. The description describes the content of a message with a message identifier 
]; 720, 722, and whether an occurrence is a repetition or not 718 (MDT field, Message 

Description Type). Message identifier 720, 722 (octet 1 bits 7 to 1 and octet 2 of the 
message description) structure is defined more exactly in [4]. Each schedule message 
also includes a Begin Slot Number 704 field and an End Slot Number 708 field. The 
. 30 End Slot Number 708 indicates the length of the schedule period (i.e., specifically the 
number of CBS message slots about which information is provided). In the case where 
the network uses schedule messages to describe all message slots in advance, the first 
schedule message of the next schedule period will be transmitted in the message slot 
*: pointed by End Slot Number plus 1. The Begin Slot Number 704 is defined to allow 

* 35 the network to broadcast several Schedule Messages referring to the same schedule 
.* period. The Begin Slot Number 704 indicates the message slot number of the CBS 

message following the received schedule message. The network may send unscheduled 
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schedule messages during empty message slots. The network needs only update the 
Begin Slot Number 704 in an unscheduled schedule message to reflect the current 
offset within the schedule message of the next message to be transmitted. Spare bits 
706 are normally ignored by terminals. Type 702 of the schedule message is 00. More 
5 details about schedule messaging in CBS can be found in the references [4] and [5]. 

In this embodiment, a CBS schedule message is exploited as well, but as slightly 
modified (regarding the field values) it indicates forthcoming, ongoing or both MBMS 
service transmissions with capability requirements instead of CBS message properties. 
10 For example, type 702 and spare 706 fields can be used to mark the message for this 
MBMS specific purpose. As in the case of the original CBS, schedule message 
contains as many (new) service descriptions 704 as there are 1 valued bits in the 
bitmap' 702. Optional descriptions may still be used for providing whatever-desired 
extra information. Regarding MBMS services, in most cases it is not necessary to 
15 indicate the service requirements at every turn as what comes to a certain service, the 
capabilities it requires from the recipient do not probably change very often if at all. 
Hence, the modified schedule message may be broadcast as a result of changes relating 
to an activation/release of a new MBMS service, registration/arrival of new terminals 
in the system/service range, service requirements' change, timing changes etc. or if 
20 preferred, on a regular basis as in a normal CBS case. Anyhow, in this example the 
: capability class information is enclosed implicitly as the receiving terminal knows how 

.i : these MBMS service accouncements are divided in octects based on the capability 

class division. Therefore, the first two octets of the bitmap 710 provide now 
information about the upcoming new MBMS services belonging to the first capability 
'v 25 class 724 (CL 1). Octets 3 and 4 (messages/services 17-32) are respectively used to 

• \ indicate class 2 (CL 2) services and octets 5 and 6 (messages/services 33-48) class 3 

services (CL3). Thus, the message slot positions 726 (1-48) do not imply the schedule 
of forthcoming transmissions as in a standard CBS schedule message described in the 
previous chapter. Message description part 712, 714 still includes IDs 720, 722, but 
, . 30 not for occasional message but more like service identification purposes. ID 720, 722 
; m ] can be e.g. IP multicast address or APN of the corresponding service taken from the 

>• 9 indication request 501. 

• mm 

This scheme is simplified and in practise it may be better to give the indication in 
: 35 another way. The capability class can be indicated to terminals explicitly, e.g. by a 
9 [ parameter as 506 in. the indication request message 501 by which also slot positions 

can be exploited for (limited) illustration of service scheduling. It is possible to use 
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some other mechanism than the schedule message to indicate the 
requirements/adequate capability class to the terminal, for example a dedicated 
message including data about specific or all MBMS services available. Accordingly, 
the network elements utilized in providing the requirements information for MBMS 
' 5 services do not have to be the ones presented in the examples above as the requirement 
indication procedure initiator and the following transmission chain components can be 
varied to better suit different system structures, e.g. depending on the available 
connections between elements and an availability of elements in general. 

10 To clarify the actual core of the invention even more, a method according to the 
invention is presented in figure 8A. In step 820 requirements for receiving a. certain 
service are defined. They may also be received, for example, from the content 
provider. Next, the requirements are broadcast to terminals in phase 822. Finally the 
factual service data is transmitted in conformity with indicated requirements, see phase 

15 824. 

In a variant of the embodiment the system informs the terminal directly about the 
service requirements such as the number of time slots needed for the reception 
(possibly also modulation: 8PSK, GMSK etc.) without defining any MBMS classes. 
20 Naturally this kind of explicit information can be also included in the indication as 
separate parameters in addition to the explicitly or implicitly defined service class. 

Recall that with WCDMA terminals and UTRAN radio access network the radio 
technology differs from the GSM and GERAN case. Thus, the requirements that must 
25 be met in order to be able to receive the MBMS service can be different. However, the 
basic invention works as suggested before, namely that minimum requirements are 
defined either as classes or explicit requirements (e.g. 128kbit/s downlink, etc). The 
same applies for other wireless systems supporting point-to-multipoint transmission 
like DVB (Digital Video Broadcasting) or WLANs (Wireless LAN). 

30 

One detail of the invention is that whenever the service requirements are defined and 
the system announces them it is also obligated to schedule and transmit the data in a 
way that the indicated requirements are truly met. For example, if the system has 
indicated two time slots as a requirement for receiving the service it cannot schedule 
35 the data on three time slots. 



• mm 

• •m 
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In the second embodiment of the invention, the overall scenario is much alike the one 
in the first embodiment See figure 8B for a flow chart, wherein the user of a mobile 
terminal is willing 802 to join a multicast service by sending 804 a specific message 
such as a join request to the SGSN 120 or some other preferred network element of the 

5 wireless system. Different options for MBMS multicast service activation are 
presented in the reference [2]. Basically only a few additional steps are needed beyond 
the phases of MBMS broadcast service activation. The terminal typically requires for a 
MBMS context on the SGSN which after creating said context accepts the context 
request by sending a separate acknowledgement message back to the terminal. The 

10 context request may include the terminal's capability notification formulated, for 
example, as a set of parameters such as a MBMS capability class, or they may have 
been stored in the system beforehand in connection with an attach procedure/PDP 
(Packet Data Protocol) context activation (attach and activation are needed in this 
case). Anyhow, as the network element in charge, for example the BM-SC 1 10, knows 

15 the terminal's capabilities it can check 806 whether they are sufficient for the service 
reception or not by e.g. comparing them with the requirements informed by the content 
provider of the corresponding service. It may then accept/reject the join request 
depending on the situation, see phases 808 and 816. Service delivery 810 is continued 
normally, preferably in conformity with indicated requirements, until a reason such as 

20 a user request for the service release 812 pops up and the service delivery is ceased 
814. So, again there are some requirements that the terminal must meet to receive the 
service and based on the terminal capabilities a decision is made whether to receive the 
service or not. However, in this embodiment the decision is made in the 
system/network side whereas in the earlier solution the decision was made in the 

25 terminal. 

This invention has been done especially MBMS in mind. However, it could be applied 
to other cases as well, e.g. to PUSH services, where the network (whatever radio 
technology) broadcasts/multicasts any data to several terminals which decide whether 
30 to receive it or not. Ultimately, regardless of diverse details all services require some 
sort of properties from the receiving equipment and if a plurality of services exists in a 
common system, a need for indicating the service specific requirements arises. 

Referring to figure 9A, basic components of a wireless terminal 900 such as a mobile 
35 phone operable in a wireless system and capable of receiving messages including 
requirements for service reception, sending messages including capability information 
and activating/deactivating multicast/broadcast services based on received information 
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are presented. Audio parts include a microphone 901, a loudspeaker 911, few 
amplifiers 902, 912 and transducers 903, 913. Radio parts consist of TX/RX filters 
with a modulator/demodulator, an amplifier and an antenna necessary for transmitting 
and receiving the data over an air interface 904, 906, 914, 915. User interface 907 is 

5 needed for controlling the device and a display 905 for informing the user about 
current state and e.g. the memory contents of said device. Processing unit 908 controls 
the functionalities of the terminal and executes required tasks. A memory 910 chip is 
needed for program/data storing purposes. An optional wireless data interface 909 
enables connections to external devices. An essential power source/battery is not 

10 shown in the figure. 

m 

Referring to figure 9B, a network element 918 operable in a wireless system and 
capable of sending service requirement indications, receiving capability information 
and deducing on the basis of said capability information whether the sender is capable 
15 of joining a point-to-multipoint service or not is presented. It contains an interface for 
data transmission 920 with other network entities or wireless terminals, a memory 921 
for program/data storing and a processing unit 923 for internal controls and task 
execution. Optional user interface 924 and display 922 may be used to provide 
sophisticated control means for the functionalities of the element 

20 

The scope of the invention is disclosed in the following independent claims. However, 
. utilized messages, network elements, system and service specifications etc. may vary 
depending on the current scenario, still converging to the basic ideas of the invention. 
Therefore, the invention is not strictly limited to the embodiments described above. 
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3GPP2002 
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Claims 

1. A method for indicating requirements for point-to-multipoint service reception 
in a wireless system, characterized in that said method comprises the step of 

-transmitting a message indicating said requirements over the air interface to at 
5 least one terminal within the service range in order to allow the terminal to 

determine whether it is capable of receiving the service or not (822). 

2. A method of claim 1, characterized in that said message is broadcast or 
multicast to the terminals. 

3. A method of claim 1-2, characterized in that a decision of whether to "receive 
10 the service or not is made in the terminal on the basis of said indication. 

4. A method of claim 1-3, characterized in that it further comprises a step wherein 
said requirements for receiving the service are defined (820). 

5. A method of claim 1-3, characterized in that it further comprises a step wherein 
the service-related data is transmitted in conformity with indicated requirements (JB24). 

15 6. A method of claim 1-3, characterized in that said requirements are indicated in 

:* said message implicitly with an identifier associated to a certain set of requirements. 

*• 

; J 7. A method of claim 1-3, characterized in that said requirements are indicated in 

said message explicitly with parameters. 

8. A method of claim 1-7, characterized in that said system is substantially GSM 
: • 20 (Giobal System for Mobile communication)/GPRS (General Packet Radio Service) or 

UMTS (Universal Mobile Telecommunications System) system. 

9. A method of claim 1-8, characterized in that said message is transmitted to the 
terminals over radio access network. 

« 

* 

». 10. A method of claim 9, characterized in that said radio access network is GERAN 

': . 25 (GSM/EDGE Radio Access Network) or UTRAN (UMTS Terrestrial Radio Access 

too 

Network). 

11. A method of claim 1-8, characterized in that said message is originated by a 
network element. 



« ■ 
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12. A method of claim 1-11, characterized in that said message is sent by the CBC 
(Cell Broadcast Centre) or RNC/BSC (Radio Network Controller/BaseStation 
Controller). 

13. A method of claim 1-9, characterized in that said message is substantially a 
5 schedule message. 

14. A method of claim 13, characterized in that said schedule message is CBS (Cell 
Broadcast Service) service specific. 

15. A method of claim 1-7, characterized in that said message is a discrete 
indication message. 

10 16. A s method of claim 1-13, characterized in that said message indicates at least 
one of the following requirements: time slot configuration, modulation type, bit rate, 
capability class: 

17. A method of claim 1-16, characterized in that said point-to-multipoint service is 
MBMS (Multimedia Broadcast/Multicast Service). 

15 18. A method of claim 1-16, characterized in that said point-to-multipoint service is 
substantially a broadcast or multicast service. 

19. A method of claim 1-16, characterized in that said point-to-multipoint service is 
substantially a PUSH service. 

20. A method of claim 1-8, characterized in that the air interface in said system is 
20 substantially in accordance with DVB (Digital Video Broadcasting) or WLAN 

(Wireless Local Area Network) specifications. 

21. A method for indicating requirements for point-to-multipoint service reception in 
a wireless system to be performed by a terminal operable in said system, characterized 
in that said method comprises the step of 

25 -informing terminal's capabilities to said system which deduces on the basis of 

informed data whether the terminal is capable of receiving the service or not (804). 

22. A method of claim 21, characterized in that it further comprises a step (806) 
wherein the system either accepts or rejects the terminal's join request based on said 
deduction. 
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23. A method of claim 21, characterized in that said system is substantially GSM 
(Global System for Mobile communication)/GPRS (General Packet Radio Service) or 
UMTS (Universal Mobile Telecommunications System) system. 

24. A method of claim 21, characterized in that said informing is performed over a 
5 radio access network which is substantially GERAN (GSM/EDGE Radio Access 

Network) or UTRAN (UMTS Terrestrial Radio Access Network). 

25. A method of claim 21, characterized in that said informed data indicates at least 
one of the following features supported by said terminal: time slot configuration, 
modulation type, bit rate, capability class. 

m 

10 26. A method of claim 21-22, characterized in that it further comprises a step 
wherein the service-related data, is transmitted in conformity with indicated 
requirements (810). 

27. A method of claim 21-26, characterized in that said point-to-multipoint service 
is MBMS (Multimedia Broadcast/Multicast Service). 

15 28. A method of claim 21-26, characterized in that said point-to-multipoint service 
is substantially a multicast service. 

29. A method of claim 21-26, characterized in that the air interface in said systein is 
substantially in accordance with DVB (Digital Video Broadcasting) or WLAN 
(Wireless Local Area Network) specifications. 

20 30. A terminal (900) operable (904, 906, 914, 915) in a wireless system, comprising 
processing means (908) and memory means (910) for processing and storing 
instructions and data, characterized in that said terminal is arranged to receive a 
message indicating requirements for point-to-multipoint service reception and arranged 
to determine on the basis of said requirements whether it is capable of receiving the 

25 service or not. 

31. A terminal of claim 30, characterized in that it is arranged to specify said 
requirements indicated in said message by associating at least one identifier included in 
said message to a certain set of requirements. 

32. A terminal of claim 30, characterized in that it is arranged to extract said 
30 requirements directly from said message wherein said requirements are described 

explicitly. 
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33. A terminal of claim 30, characterized in that said message to be received is a 
point-to-multipoint message. 

34. A terminal of claim 30, characterized in that it is substantially a GSM (Global 
System for Mobile communication) or UMTS (Universal Mobile Telecommunications 

5 System) terminal. 

35. A terminal of claim 30, characterized in that it is arranged to extract said 
indications of service requirements from a schedule message. 

36. A terminal of claim 30, characterized in that it is arranged to extract at least one 
of the following parameters defining said requirements from said message: tame slot 

10 configuration, modulation type, bit rate, capability class. 

37. A terminal of claim 30, characterized in that it is arranged to receive said 
message from the system over the air interface congruent with DVB (Digital Video 
Broadcasting) or WLAN (Wireless Local Area Network) specifications. 

38. A terminal (900) operable (904, 906, 914, 915) in a wireless system, comprising 
15 processing means (908) and memory means (910) for processing and storing 

instructions and data, characterized in that it is arranged to inform its capabilities to 
said system for the examination of fulfilment of point-to-multipoint service reception 
requirements. 

39. A terminal of claim 38, characterized in that said informing is to be included in 
20 a join request for a multicast service. 

40. A terminal of claim 38, characterized in that it is substantially a GSM (Global 
System for Mobile communication) or UMTS (Universal Mobile Telecommunications 
System) terminal. 

41. A network element (918) operable (920) in a wireless system, comprising 
25 processing means (923) and memory means (921) for processing and storing 

instructions and data, characterized in that it is arranged to send a message indicating 
requirements for point-to-multipoint service reception to be delivered to at least one 
wireless terminal within the service range in order to allow said wireless terminal to 
determine whether it is capable of receiving the service or not. 

I 30 42. A network element of claim 41, characterized in that said message to be sent is 
a point-to-multipoint message. 
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43. A network element of claim 41, characterized in that it is arranged to define 
said requirements for receiving said point-to-multipoint service. 

44. A network element of claim 41, characterized in that it is arranged to receive 
said requirements for point-to-multipoint service reception prior indicating them 

5 45. A network element of claim 41, characterized in that it is arranged to insert said 
indication of requirements into said message by at least one identifier associated to a 
certain set of requirements. 

46. A network element of claim 41, characterized in that it is arranged to insert said 
indication of requirements into said message explicitly by at least one parameter . 

10 47. A network element of claim 41, characterized in that said it is arranged to 
operate in a GSM (Global System for Mobile communication)/GPRS (General Packet 
Radio Service) or UMTS (Universal Mobile Telecommunications System) system 

48. A network element of claim 41, characterized in that it is arranged to transmit 
said message to be delivered over radio access network. 

15 49. A network element of claim 48, characterized in that said radio access network 
is GERAN (GSM/EDGE Radio Access Network) or UTRAN (UMTS Terrestrial 
Radio Access Network). 

50. A network element of claim 41, characterized in that it is substantially the CBC 
(Cell Broadcast Centre). 

20 51. A network element of claim 41 , characterized in that said message to be sent is 
substantially a schedule message. 

52. A network element of claim 41, characterized in that said message to be sent is 
a discrete indication message. 

53. A network element of claim 41, characterized in that said message to be sent 
25 includes at least one of the following requirements: time slot configuration, modulation 

type, bit rate, capability class. 

54. A network element of claim 41, characterized in that said point-to-multipoint 
service is MBMS (Multimedia Broadcast/Multicast Service). 
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55. A network element of claim 41, characterized in that said point-to-multipoint 
service is substantially a broadcast or multicast service. 

56. A network element of claim 41, characterized in that the air interface in said 
system is substantially in accordance with DVB (Digital Video Broadcasting) or 

5 WLAN (Wireless Local Area Network) specifications. 

57. A network element (918) operable (920) in a wireless system, comprising 
processing means (923) and memory means (921) for processing and storing 
instructions and data, characterized in that it is arranged to receive a notification from 
a terminal and deduce on the basis of said notification whether the terminal is capable 

10 of receiving a point-to-multipoint service or not. 

58. A' network element of claim 57, characterized in that it is arranged to accept or 
reject the terminal's join request based on said decision. 

59. A network element of claim 57, characterized in that said point-to-multipoint 
service is MBMS (Multimedia Broadcast/Multicast Service). 

15 60. A network element of claim 57, characterized in that said point-to-multipoint 
service is substantially a multicast service. 

61. A network element of claim 57, characterized in that the air interface in said 

I m m 

:* system is substantially in accordance with DVB (Digital Video Broadcasting) or 

WLAN (Wireless Local Area Network) specifications. 

20 62. A system comprising a network element (918) and at least one wireless terminal 
*% (900) operable in said system, characterized in that said network element (918) 

comprises means (920) for sending a message indicating requirements for point-ten 
multipoint service reception to be delivered to at least said wireless terminal (900) 
within the service range and said terminal (900) comprises means (906, 914, 915, 910) 

25 for receiving said broadcast message indicating requirements for point-to-multipoint 
service reception and means (908) for determining on the basis of said requirements 
whether it is capable of receiving the service or not. 



63. A system of claim 62, characterized in that said message to be sent is a point-to- 
multipoint message. 
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64. A system of claim 62, characterized in that said network element (918) further 
comprises means (923) for defining said requirements for point-to-multipoint service 
reception. 

65. A system of claim 62, characterized in that said network element (918) further 
comprises means (920) for receiving said requirements for point-to-multipoint service 
reception prior sending said message indicating said requirements. 



(57) Abstract 

The invention relates to a method and an arrangement for 
indicating requirements for broadcast and multicast service 
reception. A basic method comprises a step of transmitting 
a message indicating said requirements over the air 
interface to terminals within the service range. An 
alternative method comprises a step of informing terminal's 
capabilities to the system which deduces on the basis of 
informed data whether the terminal is capable of joining the 
service or not. A wireless system comprising a network 
element and at least one wireless terminal operable in said 
system is presented. Said wireless terminal is capable of 
receiving said broadcast message indicating said 
requirements and sending a capability notification. Said 
network element is capable of receiving said notification 
and sending said message indicating said requirements. 
Service requirements and corresponding terminal 
capabilities are divided into a number of capability classes 
which can be announced instead of explicit data. 
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